Embedded software for controlling the operation of complex real-world systems is often designed using the model-based development (MBD) paradigm. In this paradigm, designers develop a model of the physical aspects of the system, known as the plant model 10, and also develop a model of the embedded real-time software, known as the controller model 20, as shown in FIG. 1. Typically, such models are developed using a block-diagram based visual programming language such as Simulink® (a product of Mathworks in Natick, Mass.). Once the plant model 10 and the controller model 20 are developed, designers then combine these models to obtain a closed-loop model 30. The inputs 40 to the closed-loop model 30 are exogenous inputs to the plant model 10 (such as ambient temperature, atmospheric pressure, driver input, pilot commands, etc.), and outputs of the plant model 10 typically include controlled signals of the plant model 10. Typically, a closed-loop model 10 also has a number of parameters including initial conditions of various state-carrying elements in the model. This includes initial values for memory elements in the controller model 20 and the initial configuration for the physical elements in the plant model 10.
The purpose of an embedded control system is to respond to disturbances from the environment or changes to a set-point performed by the plant operation. This may involve ensuring that a particular controlled signal tracks changes in a given (fixed or dynamic) reference value. In order to do so, the controller provides inputs to the plant to regulate its behavior.
In many instances, control designers articulate the correctness of a closed-loop control system using mathematical notions of dynamic system stability. Determining if a closed-loop model 30 performs as expected is usually done by observing the closed-loop system performance in response to dynamic disturbances in its environment. The observations are often expected to indicate stable or convergent behavior, in some sense, but checking for this behavior can be challenging and usually consists of applying a collection of ad-hoc methods.
Stability analysis can be employed to determine whether a system design will exhibit convergent behaviors, but formally checking whether a system is stable requires rigorous mathematical reasoning. Checking stability in a strict mathematical fashion is infeasible in an engineering setup, where the exact symbolic form of the closed-loop system dynamics is unavailable. Even when such a precise description of the system behaviors is available, exact reasoning is often computationally infeasible. These formal checks are not often made on detailed industrial control design models, for two main reasons. First, the models are too complex, in at least the following senses: (1) they contain many state variables, and (2) they contain nonlinearities and implementation details such as controller output and sensor input saturation, transport delays due to computation times and communication delays, and quantization due to fixed-point number representations. Second, models are often represented in modeling frameworks that have proprietary semantics, such as Simulink®. For these reasons, test-based checks of stability-related properties are used in place of formal techniques.
As a result, in engineering practice, control designers often rely on control designers' experience using subjective notions of convergence. This involves observing the signal of interest and checking visually whether it converges to the desired set-point within a reasonable amount of time. This process is referred to as the stability test. Typically, a violation of the stability test manifests as oscillatory behavior around the reference value. Control designers call such behavior “hunting” or “ringing” behavior. Due to engineering concerns, prolonged hunting or ringing behavior is undesirable. In effectively testing a closed-loop control system, control designers would like to identify parameter settings (initial conditions/initial parameter values) or exogenous input values that lead the system to violate the stability test.
The manual testing and classification procedure requires the designer to select system parameters or test conditions, observe the resulting signal behaviors, and decide whether the signal converges to the desired value within reasonable time. This procedure is ad-hoc and relies on subjective notions of convergence, but it has the benefit that it utilizes engineering insight and experience. A drawback, however, is that such a subjective testing process is difficult to automate, as the convergence properties are not machine-checkable.
Accordingly, alternative systems and methods for evaluating a closed-loop control system to automatically determine stability and undesirable behaviors are desired.